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Abstract 

In mechanism design, the gold standard solution concepts are dominant strategy incentive 
compatihility and Bayesian incentive compatibility. These solution concepts relieve the (possibly 
unsophisticated) bidders from the need to engage in complicated strategizing. While incentive 
properties are simple to state, their proofs are specific to the mechanism and can be quite 
complex. This raises two concerns. From a practical perspective, checking a complex proof can 
be a tedious process, often requiring experts knowledgeable in mechanism design. Furthermore, 
from a modeling perspective, if unsophisticated agents are unconvinced of incentive properties, 
they may strategize in unpredictable ways. 

To address both concerns, we explore techniques from computer-aided verification to construct 
formal proofs of incentive properties. Because formal proofs can be automatically checked, agents 
do not need to manually check the properties, or even understand the proof. To demonstrate, 
we present the verification of a sophisticated mechanism: the generic reduction from Bayesian 
incentive compatible mechanism design to algorithm design given by Hartline, Kleinberg, and 
Malekian. This mechanism presents new challenges for formal verification, including essential use 
of randomness from both the execution of the mechanism and from the prior type distributions. 
As an immediate consequence, our work also formalizes Bayesian incentive compatibility for the 
entire family of mechanisms derived via this reduction. Finally, as an intermediate step in our 
formalization, we provide the first formal verification of incentive compatibility for the celebrated 
Vickrey-Clarke-Groves mechanism. 


1 Introduction 

Recent years have seen a surge of interest in mechanism design, as researchers explore connections 
between computer science and economics. This fruitful collaboration has produced many sophisticated 
mechanisms, including mechanism deployed in high-stakes auctions. Many mechanisms satisfy 
properties that incentivize agents to behave in a straightforward and easily modeled manner; the 
gold standard properties are dominant strategy truthful (in settings of complete information) and 
Bayesian incentive compatible (in settings of incomplete information). While existing mechanisms 
are impressive achievements, their increasing complexity raises two concerns. 

The first concern is correctness. As mechanisms become more sophisticated, proofs of their 
incentive properties have also grown in complexity, sometimes involving delicate reasoning about 
randomization or tedious case analysis. Complex mechanisms are also more prone to implementation 
errors. The second concern is more subtle. At its heart, mechanism design is algorithm design 
together with a predictive model of how agents will decide to behave. Unlike algorithm design, where 
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correctness can be verified in a vacuum, the success of a mechanism requires a realistic behavioral 
model of the participants. How will agents behave when faced with a complex mechanism? 

Different behavioral models assume different answers to this question. At one extreme, we may 
assume that agents will coordinate to play a Nash equilibrium of the game and we can study concepts 
like the price of anarchy [24, 8]. However, Nash equilibria are generally not unique, requiring 
coordination and communication to achieve [17]. Even if information is centralized, equilibria can 
be computationally hard to find [12]. Assuming that agents play at a Nash equilibrium may be 
unrealistic unless agents possess strong computational resources. 

At the other extreme, we may ask for mechanisms which are dominant strategy truthful or 
Bayesian incentive compatible. In such mechanisms, agents can do no better than truthfully reporting 
their type, even in the worst case or in expectation over the other agents’ types. These solution 
concepts assume little about the bidders: When interacting with truthful mechanisms, agents do not 
have to engage in complicated counter-speculation, communication, or computation—they merely 
have to tell the truth! 

However, even with mechanisms that are dominant strategy truthful or Bayesian incentive 
compatible, participating agents must still believe that the mechanism is truthful. For complicated 
mechanisms this is no small matter, as the incentive properties may require significant domain 
expertise to verify. We are not the first to raise these concerns. Li [21] argued for simplicity 
as a desired feature of auctions, proposing a formal definition; when designing the FCC auction 
for reallocating radio spectrum, Milgrom and Segal [22] advocated an “obviously strategy-proof” 
mechanism. 

However, some useful mechanisms are just too complex to be obvious. Gross, DeArmond, and 
Denice [14], reporting on experiences with the Denver and New Orleans school choice system, describe 
the problem: 

Both Denver and New Orleans leaders aggressively conveyed the optimal choosing strategy 
to parents, and many of the parents we spoke with had received the message. Parents 
reported to us that they were told to provide the full number of choices in their true order 
of preference. The problem was that few parents actually trusted this message. Instead, 
they commonly pursued strategies that matched their own inaccurate explanations of 
how the match worked. 

Hassidim, Marciano-Romm, Romm, and Shorrer [19] report similar behavior in a system for matching 
Psychology students to slots in graduate programs in Israel. Even though the mechanism is dominant- 
strategy incentive compatible, nearly 20% of applicants obviously misrepresented their preferences, 
with possibly more applicants manipulating their reports in more subtle ways. Instead of restricting 
mechanisms, can we give users evidence for the incentive properties? 

In this work, we consider using formal proofs as certificates. Formal proofs bear a resemblance 
to pen-and-paper proofs, but they are constructed in a rigorous fashion: They use a formal syntax, 
have a precise interpretation as a mathematical proof, and can be built with a rich palette of 
computer-assisted proof-construction tools. Compared to pen-and-paper proofs, the major benefit of 
formal proofs is that once constructed, they can be checked independently and fully automatically 
by a proof checker program. 

Several previous works have explored formal methods for verifying mechanisms; Kerber, Lange, 
and Rowat [20] provide an extensive survey. Broadly speaking, prior work falls into two groups. 
Automated approaches check properties via extensive search, guided by intelligent heuristics. These 
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techniques are more suited to verifying simpler properties of mechanisms, perhaps instantiated on a 
specific input; properties like BIC lie beyond the reach of existing approaches. 

More manual (sometimes called interactive) techniques divide the verification task into two 
separate stages. In the first stage, the formal proof is constructed. This step typically involves human 
assistance, perhaps encoding the mechanism in a specific form or constructing a formal proof. With 
the help of the human, these techniques can prove rich properties like BIC and support the level of 
generality that is typical of existing proofs—say, for an arbitrary number of agents, or for any type 
space. In the second stage, the formal proof is checked. This step proceeds fully automatically: a 
proof checking program verifies that the formal proof is constructed correctly. This neat division of 
the verification task is a natural fit for mechanism design. We could imagine that the mechanism 
designer—a sophisticated party who is intimately familiar with the details of the proof—has the 
resources and knowledge to construct the formal proof. This proof could then be transmitted to the 
agents, who can automatically check the proof with no knowledge of the details. 

The main difference between manual techniques is in the amount of human labor for proof 
construction, the most challenging phase. Existing verification approaches formalize the proof at a 
level that is far more detailed than existing proofs on paper, requiring extensive expertise in formal 
methods. Furthermore, existing works focus on general correctness properties—the output of a 
mechanism should be a partition, the prices should be non-negative, etc., rather than incentive 
properties. 

In our work, we look to combine the best of both worlds: enabling a high level of automation 
during proof construction, while supporting formal proofs that can capture rich incentive properties. 
To demonstrate our approach, the primary technical contribution of our paper is a challenging case 
study: a formal proof of Bayesian incentive compatibility (BIC) for the generic reduction from 
algorithm design to mechanism design by Hartline, Kleinberg, and Malekian [18]. This example is 
an attractive proof-of-concept for several reasons. 

1. Both the reduction and the proof of Bayesian incentive compatibility are complex. The 
mechanism is far from obviously strategy proof—indeed, the proof is a research contribution 
first published at SODA 2011. 

2. It is a general reduction, so certifying its correctness once certifies the incentive properties for 
any instantiation of the reduction. 

3. It relies on truthfulness of the Vickrey-Clarke-Groves (VCG) mechanism. As part of our efforts, 
we provide the first formal verification of truthfulness for this classical mechanism. 

4. It employs randomization both within the algorithm and within the agent behavior—agent 
types are drawn from the known Bayesian prior. 

The formal proofs bear a resemblance to the original proof, both easing formalization and making 
the proofs more accessible to the mechanism design community. 

To formalize the proofs, we adapt techniques from program verification. We view incentive 
properties as a property of the mechanism and the agent’s payoff function, both expressed as 
programs. Formal verification has developed sophisticated tools and techniques for verifying program 
properties, but general-purpose tools require significant manual work. Verifying even moderately 
complex mechanisms seems well beyond the reach of current technology. To ease the task, we view 
incentive properties as relational properties: statements about the relationship between the outputs 


3 


in two runs of the same program. Specifically, consider the program which calculates an agent’s 
payoff under the mechanism and assume agents play their true value in the first run, while an agent 
may deviate arbitrarily in the second run. If the output in the first run is at least the output in the 
second run, then the mechanism is incentive compatible. 

With this point of view, we can use tools specialized for relational properties. Such tools are 
significantly easier to use and have achieved notable successes for verifying proofs from differential 
privacy and cryptography. We use HOARe^, a recently-developed programming language that can 
express and check relational properties [4]. HOARe^ has been used to verify differential privacy and 
basic truthfulness in simple mechanisms under complete information, like the fixed price auction and 
the random sampling mechanism of Goldberg, Hartline, Karlin, Saks, and Wright [13] for digital 
goods. 

Our work goes significantly beyond prior efforts in several respects. First, the mechanism we 
verify is significantly more complex than previously considered mechanisms, and we analyze all uses 
of the reduction, rather than just a single instance. Second, the mechanism operates in the partial 
information setting, so the proof requires careful reasoning about randomization (from both the 
mechanism and from the prior distribution on types). 

The main strength of our approach lies in the high degree of automation during proof construction. 
Once the mechanism and payoff functions have been encoded as programs, and once we have supplied 
some annotations, we can construct most of the formal proof automatically with the aid of automated 
solvers. However, there are a handful of particularly complex steps that HOARe^ fails to automatically 
prove. To finish the proof, we manually build a formal proof for these missing pieces using EasyCrypt, 
a proof assistant for relational properties, and Coq, a general purpose proof assistant.^ 

Related work. Closely related to our work, a recent paper by Caminati, Kerber, Lange, and 
Rowat [7] uses the theorem prover Isabelle to verify basic properties of the celebrated Vickrey- 
Clarke-Groves (VCG) mechanism. They consider general auction properties: the prices should be 
non-negative, VCG should produce a partition of goods, etc. Moreover, their framework can be used 
to automatically produce a correct, executable implementation of the mechanism. While their work 
demonstrates that formal verification can be applied to verify properties of mechanisms, their results 
are limited in two respects. First, they do not consider incentive properties, arguably the properties 
at the heart of mechanism design. Second, they apply general techniques from computer-aided 
verihcation that are not specihcally tailored to mechanism design, requiring substantial effort to 
produce the machine-checked proof. Our work uses verihcation techniques that are particularly 
suited for incentive properties. 

In the appendix we provide a primer on formal verihcation and discuss related work; a recent survey 
by Kerber et al. [20] provides a comprehensive review of formal methods for verifying mechanism 
design properties. The algorithmic game theory literature has for the most part ignored the problem 
of verifying incentive properties, with a few notable exceptions. Recently, Branzei and Procaccia [6] 
dehne verifiably truthful mechanisms. Informally, such a mechanism is selected from a hxed family of 
mechanisms such that for every truthful mechanism in that family, a certihcate showing truthfulness 
can be found in polynomial time. Branzei and Procaccia [6] consider mechanisms represented 
as decision trees and show that for the one-dimensional facility location problem, truthfulness 
for mechanisms in this class can be efficiently verihed by linear programming. In contrast, we 

^Our formal proofs, along with code for the HOARe^ tool, are available online: https://github.com/ejgallego/ 
H0ARe2/tree/master/examples/bic 
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investigate significantly more complex mechanisms in exchange for forgoing worst-case polynomial 
time complexity. 

Mu’alem [23] considers the problem of property testing for truthfulness in single parameter 
domains, which reduces to testing for a variant of monotonicity. Mu’alem [23] gives a tester that can 
test whether there exist payments that guarantee that truthful reporting is a dominant strategy 
with probability 1 — e, given a poly (1/e) number of arbitrary evaluations of an allocation rule and 
assuming agents have uniformly random valuations. In contrast, we assume direct access to the 
code specifying the auction instead of merely black box access to the allocation rule, and we achieve 
verification of exact truthfulness, not just approximate truthfulness. We are also able to verify 
mechanisms in more complex settings, e.g., arbitrary type spaces, randomized mechanisms, and 
arbitrary priors. 

Our work is also related to the literature on automated mechanism design, initiated by Conitzer 
and Sandholm [11] (see Sandholm [25] or Conitzer [10, Chapter 6] for an introduction). In broad 
strokes, automated mechanism design seeks to generate truthful mechanisms which optimize the 
designer’s objectives. This is often accomplished by solving explicitly for the distribution on outcomes 
defining a mechanism using a mixed integer linear program encoding the incentive constraints 
and objective, an NP hard problem that can often be solved efficiently on typical instances [10]. 
Automated mechanism design targets a more difficult problem than we do: it seeks not just to verify 
the truthfulness of a given mechanism, but to optimize over all truthful mechanisms. However, these 
techniques have some limitations: they produce explicit representations of mechanisms requiring size 
exponential in the number of bidders, and they use an explicit integer linear program, requiring a 
finite type space. In contrast, by only requiring full automation for proof verification and not proof 
construction, we are able to use a much more sophisticated toolkit—including symbolic manipulation, 
not just numeric optimization—and verify significantly more complex mechanisms that can have 
inhnite outcome and type spaces. 

2 Main example: RSM 

As our main proof of concept, we verify that the Replica-Surrogate-Matching (RSM) mechanism due 
to Hartline et al. [18] is Bayesian incentive compatible. The RSM mechanism reduces mechanism 
design to algorithm design: given an algorithm A that takes in agents’ reported types and selects an 
outcome, the RSM mechanism turns A into a Bayesian incentive compatible mechanism. Accordingly, 
our formal proof will carry over to any instantiation of RSM. We hrst review the original proof by 
Hartline et al. [18]. Then, we describe our verihcation process, from pseudocode to a fully verihed 
mechanism. 

Let’s begin with the standard notion of Bayesian incentive compatibility. We assume there are 
n agents, each with a type ti drawn from some set of types T. Furthermore, we have access to 
a distribution [i on types, the prior. A mechanism is a (possibly randomized) function from the 
inputs—one per agent—to a single outcome o from set O, and a real-valued payment pi for each 
agent. Without loss of generality, we will assume that the agents each report a type from T as their 
input. Agents have a valuation v{t,o) for type t and outcome o. Agents have quasi-linear utility: 
their utility for outcome o and payment p is u(t, o) — p. We will write (s, t-i) for the vector obtained 
by inserting s into the zth slot of t. Then, we want to check the following property. 

Definition 2.1. A mechanism M is Bayesian incentive compatible (BIC) if for every agent i and 


5 


1. Pick i uniformly at random from [m]; 

2. Build a replica type profile r by taking m — 1 samples from /i for f-i, setting = t; 

3. Build a surrogate type profile sby taking m samples from /r; 

4. Build a bipartite graph with nodes r, s, and edges with weight 

w{r,s) = Ei._.^^u-i[v{r, A{s,t-i))]; 

5. Run the VCG procedure on the generated graph, and return the surrogate s that is matched 
to the replica in slot i, and the appropriate payment p. 

Figure 1: Procedure R with parameter m 


types ti,fi, we have 

M{ti,t_i)) -pi{ti,t_i)] ^ - pi{ti,t-i)]. 

The expectation is taken over the types t-i of the other agents (drawn independently from /i ) and 
any randomness used by the mechanism. 

2.1 The RSM mechanism 

Now, let’s consider the mechanism: the RSM mechanism in the “idealized model” by Hartline et al. 
[18]. We will first recapitulate their proof, before explaining in detail how we verify it. 

RSM is a construction for turning an algorithm A : T” ^ O into a BIG mechanism. The process 
is easy to describe: each agent individually transforms their type ti to a surrogate type Si by applying 
the Replica-Surrogate-Matching procedure R. This procedure also produces a payment pi for the 
agent. Then, the surrogates s are fed into the algorithm A, which produces the final outcome. 

The procedure R is described in Figure 1. Let m be an integer parameter—the number of 
replicas. Given input type t, we take m — 1 independent samples from /r, the (r)eplicas. We then 
take m independent samples from /r, the (s)urrogates. Finally, we select an index i uniformly at 
random from [m], and place the original type t in the ith “slot” of the replicas r. We will consider 
the replicas as “buyers”, and the surrogates as “goods”, and assign a numeric “value” for every pair of 
buyer and good. The value of replica r for surrogate s is set to be 

w{r,s) = Et_..^^n-i[v{r, A{s,t-i))], (1) 

that is, the expected utility of an agent with true type r reporting type s. Finally, RSM runs the 
well-known Vickrey-Glarke-Groves mechanism [26, 9, 15] to match each replica with a surrogate in 
this market. The output is the surrogate matched to replica in slot i (the original type t), along 
with the payment charged. 

The original proof. The proof of BIG from Hartline et al. [18] proceeds in two steps. First, they 
show that R is distribution preserving. 
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Lemma 2.1 (Hartline et al. [18]). Sampling a type t p, as input to R gives the same distribution 
(p) on the surrogates output. 

Proof. When R constructs the list of buyers before applying VCG, the distribution over buyers 
is simply m independent samples from p, no matter the value of i. So, we can delay sampling i 
and selecting the surrogate until after running VCG (via the principle of deferred decision). VCG 
produces a perfect matching of replicas to surrogates, and the surrogates are also m independent 
samples from p. So, sampling a random replica i and returning the matched surrogate is an unbiased 
sample from p. □ 

With the lemma in hand, Hartline et al. [18] show that RSM is BIG. 

Theorem 2.1 (Hartline et al. [18]). The RSM mechanism is BIC. 

Proof. Consider bidder i with type ti, and fix the randomness for bidder i. In the VCG procedure 
of R, the value of i’s replica for surrogate s is w{ti, s): the expected utility for submitting s to H 
while having true type ti, assuming that all other inputs to A are drawn from p. 

In the RSM mechanism, the other inputs to A are computed by sampling a type tj ~ p, and 
taking the surrogate produced by R{tj). By Lemma 2.1, the distribution over surrogates is p. 
Therefore, w{ti,s) is bidder i's expected utility in the RSM mechanism for ending up matched to 
s. Since VCG is incentive compatible, bidder i has no incentive to deviate to any other bid t[. By 
taking expectation over the randomness of i, we get the result. □ 

Crucially, Theorem 2.1 relies on the truthfulness property of the VCG mechanism. We have also 
verihed this property but we postpone our discussion to Appendix B; the verihcation of RSM is 
more interesting. 


3 Verifying RSM 

Now that we have seen the mechanism, we present our verification step by step. 


1. We write the RSM mechanism as a program in the 
HOARe^ programming language. 

2. We annotate the program with assertions expressing 
the BIC property, and some additional intermediate 
facts (lemmas). 

3. The tool automatically generates the verification con¬ 
ditions (VCs), which imply BIC. 

4. The tool uses automatic solvers to check the verification 
conditions; they may fail to prove some assertions. 


program encoding the mechanism 


[expert adds asscrtion.sj 


annotated program 


[ proof checker generates VCs j 


collection of VCs 


[automatic solver checks VCs] 


VCs not solvable automatically 


[solve VCs in interactive solver] 


proof of incentive property 


5. Finally, we prove the remaining verification conditions 
by using an interactive prover. 

The outcome of these hve steps is a formal proof that the RSM mechanism enjoys the BIC 
property. In the following, we will combine the description of different steps in the same subsection. 
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1 def Rsmdet(], coins, truety, report) = 

2 ( rs_ i, ss, i) = coins; 

3 vcgbuyers = (report, rs_i); 

4 (surrs, pays) = Vcg(vcgbuyers, ss); 

5 return (surrs[]], pays[j]) 


1 def Expwts(j, r, s) = 

2 sample others 

3 alginput = (s, others_j); 

4 outcome = alg(alginput); 

5 return expect-num { value(r, outcome) } 


Figure 2: Defining RSM 


Figure 3: Defining weights 


Step 1: Modeling the mechanism 

To express RSM as a program, we will code a single agent’s utility function when running the RSM 
mechanism, when all the other agents report truthfully and have types drawn from /i. Remembering 
that we consider truthfulness as a relational property, we will then reason about what happens when 
the agent reports truthfully, compared to what happens when the agent deviates. 

We model types and outcomes as drawn from (unspecified) sets T and O, and we assume an 
algorithm alg mapping T” —> O. We will consider what happens when the first bidder deviates. 
This is without loss of generality: if j deviates, we can consider the RSM mechanism with alg 
replaced by a version alg ' that hrst rotates the jth bidder to the hrst slot, when proving BIC for 
the first bidder under alg ' implies BIC for the jth bidder under A. For the values, we will assume 
an arbitrary valuation function value mapping T x O —> M. In the code, we will write mu for the 
prior distribution p,. 

Let’s begin by coding the RSM transformation R, which transforms an agent’s type into a 
surrogate type and a payment. It will be convenient to separate the randomness from R. We encode 
R as a deterministic function Rsmdet, which takes as input the agent number j, the random coins 
coins, and the input type report. We will have Rsmdet take an additional parameter truety 
representing an agent’s true type. This variable does not show up in the code-RSM does not have 
access to this information—but will be useful later for expressing Bayesian incentive compatibility 
as a relational property. We will model the slot as a natural number. 

In Appendix B we will discuss our treatment of VCG in more detail, but it is enough to know 
that VCG takes a list of buyers and a list of goods. VGG will output a permutation of goods 
(representing the assignment), and a corresponding list of payments. In Figure 2, bolded words 
are keywords and primitive operations of HOARe^. For a brief explanation, line (2) names the 
three components of coins: the replicas rs_j, the surrogates ss, and the slot i; line (3) puts the 
agent’s input type report in the proper slot for the replicas; line (4) calls VCG on the list of buyers 
vcgbuyers produced at line (3) and the list of surrogates ss as goods; and line (5) returns the 
surrogate and payment. 

The Expwts function in Figure 3 implements the w function from Equation (1), with the 
additional parameter j to indicate the agent. In Figure 3, line (2) samples n — 1 types others_j 
from p for the other agents. These are the types on which the expectation is taken in Equation (1). 
Line (4) uses the algorithm alg to compute the outcome outcome when the agent j report type s. 
Finally, the expect_num on line (5) takes the expected value of the distribution over reals defined by 
evaluating the value function value on the true type r and on the randomized outcome of the alg. 

To check the BIC property, we will code the expected utility for the first bidder and then check 
that it is maximized by truthful reporting. To break down the code, we will suppose that the 
function takes in a list of functions othermoves that transform each of the other bidder’s type. 

The distribution rsmcoins defines the distribution over the coins to R, i.e., sampling the replicas 



1 def Util(othermoves, myty, mybid) = 

2 return (expect rsmcoins Helper) 

3 

4 def Helper(coins) = 

5 (mysur, mypay) = 

6 Rsmdet(l, coins, myty, mybid); 

7 myval = expect-num { 

8 for i = 1 ... n — 1: 

9 sample othersurs[i] = 

10 (sample otherty = mu; 

11 othermoves[i](otherty)); 

12 alginput = (mysur, othersurs); 

13 outcome = alg(alglnput); 

14 value(myty, outcome) }; 

15 return (myval - mypay) 


Figure 4: Defining utility 


1 def Others(;j, t) = 

2 sample coins = rsmcoins; 

3 (s, p) = Rsmdet(], coins, t); 

4 return s 

5 

6 def MyUtil(ty,bid) = Util(Others,ty,bid) 


Figure 5: Defining other reports 


r_j, the surrogates s, and the coin i. We encoded this distribution in HOARe^, but we elide it for lack 
of space. In the code in Figure 4, on line (2) we take expectation of the function Helper over the 
distribution rsmcoins, with expect. In Helper, we then call Rsmdet on line (6) to compute the 
surrogate and payment for the agent, passing 1 since we are calculating the utility for the first agent. 
We sample the other agents’ types and transform them on lines (9-11), and we take expectation of 
the first agent’s value for the outcome on lines (7-14). Finally, we subtract off the payment on line 
(15), giving the final utility for the first agent. 

To complete our modeling of RSM, in Figure 5 we plug in Others into the utility function: it 
simply takes an agent number and a type as input, samples the coins from rsmcoins, and returns 
the surrogate from calling Rsmdet. So far, we have just written code describing how to implement 
the RSM mechanism and how to calculate the utility for a single bidder. Now, we express the BIG 
property as a property about this program and check it with HOARe^. 

Step 2: Adding assertions 

We specify properties in HOARe^ by annotating variable and functions with assertions of the 
form {x :: Q \ 0}, read as “x is an element of set Q and satisfies the logical formula cj)". These 
assertions serve two purposes: (1) they express facts to be proved about the code and (2) they assert 
mathematical facts about primitive operations like expect and expect_num. The system will then 
formally verify that the first kind of annotations are correct, while assuming the assertions of the 
second kind as axioms. 

A key feature of HOARe^ is that the assertion cj) is relational: it can refer to two copies of each 
variable x, denoted xi and X 2 - Roughly, we may make assertions about two runs of the same program 
where in the first program we use variables xi, and in the second run we use variables X 2 .^ For 
instance, truthfulness corresponds to the following assertions: 

{ty :: T \ tyi = ty 2 } (true type is equal on both runs) 

[bid :: T \ bidi = tyi} (bid is the true type in the first run) 

[utility :: M | utilityi ^ utility 2 } (utility is higher in the first run) 

Our goal is to check these assertions for the function MyUtil, which computes an agent’s utility 
in expectation over the other types. Along the way we will use several intermediate facts, encoded 

^These annotations are known as relational refinement types in the programming language literature. We will call 
them assertions or annotations to avoid clashing with agent types. 
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as assertions in H 0 ARe 2 . Assertions on primitive operations, like expect and expect_num, are 
the axioms. Assertions on larger chunks of code are proved correct from the assertions on the 
subcomponents. 

Monotonicity of expectation. Since the BIC property refers to expected utility, we use an 
expectation operation expect when computing an agent’s utility (line (2) of the Util code). To 
show BIC, we need a standard fact about monotonicity of expected value: for functions f ^ g, 
E[/] ^ E[gf] taken over the same distribution. This can be encoded with an annotation for expect: 

distrjc :: C I Cl = C 2 } ^ {/ :: C ^ M | Vx. /i(x) ^ f 2 {x)} —> {e :: M | ei ^ 62 }. 

This annotation indicates that expect is a function that takes two arguments and returns a real 
number. In each of the three components, the annotation before the bar specihes the type of the 
value: The hrst argument is a distribution over C, the second argument is a real-valued function 
C —> M, and the return value is a real number. The logical formulas after the pipe describe how 
two runs of the expectation function are related. The hrst component states that in the two runs, 
the distributions are the same. The second component states that the function / in the hrst run is 
pointwise less than / in the second run. The hnal component asserts that the expected value—a 
real number—is less on the hrst run than on the second run. 

If think of the distribution as being over the coins rsmcoins, this fact allows us to prove 
deterministic truthfulness for each setting of the coins, then take expectation over the coins in order 
to show truthfulness in expectation. This is what we need to prove for the BIC property, and is 
precisely the hrst step in the original proof of Theorem 2.1. 

Distribution preservation. When we consider a single agent, truthful bidding may not be BIC 
for arbitrary transformations of the other agents’ types (othermoves in the Util code). As indicated 
by Lemma 2.1, we also need the transformation to be distribution preserving: the output distribution 
on surrogates must be the same as the distribution on input types. 

Much as we did above, we can capture this property with appropriate annotations. While we 
have so far used rather simple formulas (p that only mention variables in {x :: T | (/)}, in general the 
formulas cp can describe assertions about programs.^ We can annotate the othermoves argument to 
Util to require distribution independence: 

{othermoves I list (T —> dlStrr) I \f j 6 [^] • (sample ot = mu; othermoves[j ] (ot)) — mu} 

To read this, othermoves is a list of functions fj that take a type and return a distribution on 
types, such that if we sample a type from mu and feed it to fj, the resulting distribution (including 
randomness over the initial choice of type) is equal to mu. In other words, this asserts the distribution 
preservation property of Lemma 2.1 for each of the other agent’s transformations. 

Facts about VCG. Recall that Vcg takes a list of bidders and a list of goods, and produces a 
permutation of the goods and a list of payments as output. In our case, the bidders and goods are 
both represented as types in T, so we can annotate the Vcg as: 

{buys :: listT} —> [goods :: listT} —> {{alloc,pays) :: listT x listM | vcgiruth a vcgperm}. 

^Of course, we need to actually check the assertions eventually, whether by automated solvers or manual techniques. 
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The two assertions vcgimth and vcgperm reflect two facts about VCG. The first is that VCG is incentive 
compatible; this can be encoded like we have already seen, with a slight twist: We require that VGG 
is IG for a deviation by any player rather than just the first player, since the possibly deviating 
player may be in any slot. More precisely, we define the formula 

vcgTruth : = V ] G ['ll] • (~ J T ~ ~ J ^ 

Expwts(:, bidsi[j], aUoci[j]) — paysi[j] ^ Expwts(j, bidsi[j], alloc 2 [:])) ~ pays 2 [jl. 

We treat the bid in the first run (bidsi[j]) as the true type, and the bid on the second run (bids 2 [:]) 
as a possible deviation—this is why we evaluate the jth bidder’s expected utility using the same 
true type in the two runs. The second fact we use is that VGG matches buyers to the goods. In 
fact, since the number of goods (surrogates) and the number of buyers (replicas) are equal, VGG 
produces a perfect matching. We express this by asserting that VGG outputs an assignment that is 
a permutation of the goods: 


vcgPerm I— isPerm goodsi alloci A isPerm goods 2 alloc 2 . 


We verify these properties for a general version of VGG. The verification follows much like the current 
verification; we discuss the details in Appendix B. 

Step 3: Handling proof obligations 

After providing the annotations, HOARe^ is able to automatically check most of the annotations with 
SMT solvers ^—fully automated solvers that check the validity of logical formulas. Such solvers are a 
staple of modern formal verification. While the underlying problem is often undecidable, modern 
solvers employ sophisticated heuristics that can efficiently handle large formulas in practice. 

We are able to use SMT solvers to automatically check all but three proof obligations; for these 
three facts the SMT solvers time out without finding a proof. The first two are uninteresting, and 
we manually construct the formal proof using the Goq proof assistant. The last obligation is more 
interesting: it corresponds to Lemma 2.1. Goncretely, when we define an agent’s expected utility 


def MyUtil(ty,bid) = Util(Others,ty.bid), 

recall that Util asserts that Others is distribution preserving. This is precisely Lemma 2.1, and 
the automated solvers fail to prove this automatically. 

To handle this assertion we use a more manual tool called EasyGrypt [2, 3], a proof assistant 
that allows the user prove equivalence of two programs A and B by manually transforming the 
source code of A until the source code is identical to B.^ We prove that Others is equivalent to 
the program that simply samples from mu by transforming the code for Others (including the code 
sampling the coins of the mechanism, rsmcoins) in several stages. We present the code in Figure 6 
with two replicas, for simplicity. 

The proof boils down to showing that each step transforms a program to an equivalent program. 
Our starting point is stagel, the program that samples an agent’s type from mu and runs Others 
on the sampled value. Unfolding the definition of Others, Rsmdet, rsmcoins and including the 
code that puts the agent’s input type in the proper slot for the replicas, we obtain program Stage2. 

'^Satisfiability-Modulo-Theory, see e.g., [1] for a survey. 

®This is a common proof technique in cryptographic proofs, known as game hopping [5, 16]. 
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def stagel = def stage2 = 

sample ot = mu; sample ot = mu; 

Others(ot) sample r' = mu; 

sample si = mu; 
sample s2 = mu; 
sample i = flip; 

if i then 

(rl,r2) = (ot.r'); 
else 

(rl,r2) = (r',ot); 

bs = (rl,r2); 
gs = (sl,s2); 

(ss,ps) = Vcg(bs,gs); 
(ol,o2) = ss; 

if i then ol else o2 


def Stages = 
sample ot = mu; 
sample r' = mu; 
sample si = mu; 
sample s2 = mu; 

(rl,r2) = (ot,r'); 

bs = (rl,r2); 
gs = (si,s2); 

(ss,ps) = Vcg(bs,gs); 
(ol,o2) = ss; 

sample i = flip; 
if i then ol else o2 


def stage4 = 
sample si = mu; 
sample s2 = mu; 
sample i = flip; 
if i then si 
else s2 


Figure 6: Code transformations to prove Lemma 2.1. 


From there, the main step is to show that we don’t need to place the replicas in a random order 
before calling Vcg. Then, we can move the sampling for i down past the Vcg call, giving stageB. 
Finally, using the fact that the output assignment SS of Vcg is a permutation of the goods (sl, s2), 
we obtain the program Stage4 and conclude that this is equivalent to taking a single sample from 
mu. This chain of transformations has been verified with EasyCrypt. 

4 Perspective 

Now that we have presented our verihcation of the RSM mechanism, what have we learned and 
what does formal verihcation have to offer mechanism design going forward? In our experience, 
while formal verihcation of game theoretic mechanisms is by no means trivial, verihcation tools are 
maturing to a point where practical verihcation of complex mechanisms can be envisioned. Our 
verihcation of RSM, for instance, involved only coding the utility function and adding annotations, 
most of which can be checked automatically. The most time-consuming part was manually proving 
the last few assertions. 

At the same time, the range of mechanisms that can be verihed is less clear. There is an art 
to encoding a mechanism in the right way, and some mechanisms are easier to verify than others. 
Since we are trying to verify proofs, the crucial factor is the complexity of the proof rather than the 
complexity of the mechanism. Clean proofs where, each step reasons about localized parts of the 
program, are more amenable to verification; proof patterns—like universal truthfulness—also help. 

In sum, formal verihcation can manage the increasing complexity of mechanisms by formally 
proving incentive properties for everyone—mechanism designers, mechanism users, and even mecha¬ 
nism programmers. We believe that the tools to verify one-shot mechanisms are already here. So, 
we propose a challenge: Try using tools like HOARe^ to verify your own mechanisms, putting formal 
verihcation techniques to the test. We hope that one day soon, verihcation for mechanisms will be 
both easy and commonplace. 
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A A note about worst-case complexity 


As is typical in program verification, we distinguish between constructing a proof and checking 
it. Constructing the proof is hard: we do not assume that a proof (or some representation, like 
a certihcate) can be found automatically in worst-case polynomial time, and we will even allow a 
human to play a limited part in this process. However, checking the proof must be easy: agents 
should be able to take the formal proof and check it in polynomial time. 

While worst-case polynomial time for the entire process would be ideal, it is not very realistic as 
we cannot expect an algorithm to prove the incentive properties automatically—the proof may be a 
research contribution; deciding whether an incentive property holds at all may be an undecidable 
problem. However, relaxing the running time condition when constructing the proof is well-motivated 
in our application. Unlike the mechanism itself, the proof construction procedure will not be run 
many times on inputs of unknown origin and varying size. Instead, for a particular mechanism, the 
proof is constructed just once. In exchange for relaxing worst-case running time, we can verify rich 
classes of mechanisms. 

B Verifying the VCG Mechanism 

The celebrated VCG mechanism is a foundational result in the mechanism design literature. It 
calculates an outcome maximizing social welfare (i.e., the sum of all the agents’ valuations) and 
payments ensuring that truthful bidding is incentive compatible. Let’s briefly review the definition. 

Definition B.l (Vickrey [23], Clarke [8], Groves [14]). Let O be a space of outcomes, and let 
u : T X O —> M map agent types and outcomes to real values. Given a reported type profile t from n 
agents, the VCG mechanism selects the social-welfare maximizing outcome: 

o* := argmax \ v{ti,o), 

oeO -^r n 
2 G [n\ 

and computes payments 

Pj\=m&x ^ v{ti,o)- Yj v{ti,o*). 

*s[n]\{j} 

That is, the payment for agent j is the difference between the welfare for the other agents without j 
present, and the welfare for the other agents with j present. 

As Vickrey, Clarke, and Groves showed, this mechanism is incentive compatible. Let’s consider 
how to verify this fact in HOARe^. Like for RSM, we will start by coding the utility function 
for a single bidder. We will call it VcgM to distinguish it from the more special case we need for 
RSM; Figure 7 presents the full code. The parameters to VcgM are a list of valuation functions 
(values) and a set of possible outcomes (range). We use two helper functions: sumFuns takes a 
list of valuation functions and sums them to form the social welfare function, while findMax takes a 
objective function and a set of outcomes, and returns the outcome maximizing the objective. 

To encode the incentive property, we will consider two runs of VcgM. We allow any single agent 
to deviate on the two runs. For the deviating agent, we will model her report in the first run will be 
her“true” valuation. Then, we want to give VcgM the following annotation: 

{values : O —> —> {range : IlStO} —> {(out,pays) '. O X IlStM | out G range A vcgTruthj. 
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1 def VcgM(values, range) = 

2 welfare = sumFuns(values); 

3 outcome = findMax(welfare, range); 

4 

5 for i = 1 ... n\ 

6 welfWithout = sumFuns(values-^); 

7 outWithout = findMax(welfWithout, range); 

8 pricesli] = welfWithout(outWithout) - welfWithout(outcome) 

9 end 
10 

11 (outcome, prices) 


Figure 7: Encoding the VCG mechanism in HOARe^ 


The predicate vcgimth captures truthfulness, like the assertion in § 3: 

vcgTruth 1= Vj 6 [m] . (values_j^]^ = values — ^ 2 ) 

values[jl 1 (outi [j]) — paysi[:] ^ values[j] 1 (out 2 [j ]) — pays 2 [:]. 

With appropriate annotations on findMax, sumFuns, and the “all-but-j” operation ( —)_j, HOARe^ verifies 
VCG automatically. 

C A primer on program verification 

Program correctness and program verification have a venerable history. In a visionary article, Turing 
[22] presents a rigorous proof of correctness for a computer routine; although very short, this note 
prefigures the current trends in deductive program verification and introduces many fundamental 
ideas and concepts that still remain at the core of program verification today. In particular, Turing 
makes a clear distinction between the programmer and the verifier, and argues that in order to 
alleviate the task of the verifier, the programmer should annotate his code with assertions, i.e. 
predicates on program states. Moreover, Turing argues that it should be possible to verify assertions 
locally and that the correctness of the routine should be expressed by the initial and final assertions, 
i.e. the assertions attached to the entry and exit points, which respectively capture hypotheses on 
the program inputs and claims about the program outputs. 

Leveraging contemporary developments in programming language theory, the seminal works of 
Floyd [12] and Hoare [15] formalize verification methods that adhere to the program proposed by 
Turing. Both formalisms share similar principles and make a central use of invariants for reasoning 
about programs with complex control-flow; for instance, both methods use loop invariants —assertions 
that hold when the program enters a loop and remain valid during loop iterations. However, the 
methods differ in the specifics of proving program correctness. On the one hand, Hoare logic provides 
a proof system —a set of axioms and rules for combining axioms—that can be used to build valid 
formal proofs that establish program correctness. On the other hand, Floyd calculus computes—from 
an annotated program—a set of verification conditions: formulas of some formal language such as 
first-order logic, whose validity implies correctness of the program. Despite their differences, the 
two approaches can be proved equivalent, and assuming that the underlying language of assertions 
is sufficiently expressive, are relatively complete [10]; relative completeness reduces the validity of 
program specifications to the validity of assertions. 

Both Floyd [12] and Hoare [15] are designed to reason about properties, i.e. sets of program 
executions. They cannot reason about the larger class of hyperproperties [9], which characterize sets 


16 



of sets of program executions. Continuity (small variations on the input induce small variations on 
the output), and truthfulness (pay-off is maximized when agents play their true value) are prominent 
binary instances of hyperproperties, also called relational properties. Reasoning about relational 
properties is challenging and the subject of active research in programming languages. One way 
for reasoning about such properties is by using relational variants of Floyd [12] and Hoare [15]. 
These variants [6] reason about two programs (or two copies of the same program) and use so-called 
relational assertions, assertions which describe pairs of states. 

Another challenge in program verification is to deal with probabilistic programs. Starting from 
the seminal work of Kozen [16], numerous logics have been proposed to reason about properties 
of probabilistic programs, including [18, 7]. Recently, Barthe, Gregoire, and Zanella-Beguelin [3] 
propose a relational logic for reasoning about probabilistic programs. Barthe et al. [5] extend and 
generalize the relational logic to the setting of a higher-order programming language. 

In recent years, the theoretical advances in program verification have been matched by the 
emergence of computer-aided verification tools that have successfully validated large software 
developments. Most tools implement algorithms for computing verification conditions; the algorithms 
are similar in spirit to Floyd [12], although they typically use optimizations [11]. Moreover, most 
systems use fully automated tools to check that verification conditions are valid. However, there 
is a growing trend to complement this process with an interactive phase, where the programmer 
interactively builds a proof of difficult verihcation conditions that cannot be proved automatically. 
Contrary to automated tools, which try to find a proof of validity, interactive tools try to check that 
the proof of validity built interactively by the programmer is indeed a valid proof. This interactive 
phase is often required for proving rich properties of complex programs. It is also often helpful for 
proving relational properties of probabilistic programs [4]. 

So far, our account of formal verification has focused on so-called deductive methods: methods 
where the verification corresponds to build formal proofs that can be constructed using a finite set of 
rules starting from a given set of axioms. However, there are many alternative methods for proving 
program correctness. In particular, algorithmic methods, such as model-checking, have been highly 
successful for analyzing properties of large systems. Algorithmic methods are fundamentally limited 
by the state explosion problem, since the methods become intractable when the state space becomes 
too large. Modern tools based on algorithmic verification exploit a number of insights for alleviating 
the state explosion problem, including symbolic representations of the state space, partial order 
reduction techniques, and abstraction/refinement techniques. 

D Related Work in Computer-aided Program Verification 

There is a small amount of work in the programming languages and computer-aided program 
verification literature on verification of truthfulness in mechanism design. Lapets, Levin, and Parkes 
[17] give an interesting approach, by presenting a programming language for automatically verifying 
simple auction mechanisms. A key component of the language is a type analysis to determine if 
an algorithm is monotone] if bidders have a single real number as their value {single-parameter 
domains), then truthfulness is equivalent to a monotonicity property (e.g., see Mu’alem and Nisan 
[19]). Their language can be extended by means of user-defined primitives that preserve monotonicity. 
The paper shows the use of the language for verifying two simple auction examples, but it is unclear 
how this approach scales to larger auctions, and does not extend beyond single parameter domains. 
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Wooldridge, Agotnes, Dunne, and van der Hoek [24] promote the use of automatic verification 
techniques where mechanism design properties are described by means of specification logics (like 
Alternating Temporal Logic [1]), and where the verification is performed in an automatic way by 
using the model checking technique. Similarly, Tadjouddine and Guerin [20] propose a similar 
approach where first order logic is used as a specification logic. This approach works well for simple 
auctions with few numbers of bidders but suffers from a state explosion problem when the auctions 
are complex or the number of bidders is large. This situation can be alleviated by combining different 
engineering techniques [21], but it is unclear if this approach can be scaled to handle complex 
auctions with a large number of bidders. Moreover, these automatic approaches do not work in 
setting of incomplete information. 

An alternative approach based on interactive theorem proving has been explored by Bai, Tad¬ 
jouddine, Payne, and Guan [2]. Interactive theorem provers allows specifying and formally reasoning 
about arbitrary auctions and different truthfulness properties. More generally, they have been used 
to formalize large theorems in mathematics [13]. Unfortunately, verifying the required properties 
can require advanced proof engineering skills, even for very simple auctions; Bai et al. [2] consider 
the English and Vickrey auctions. 
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